feat(metrics): Trace-connected Metrics (Analyzers)#4840
feat(metrics): Trace-connected Metrics (Analyzers)#4840
Conversation
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Features
- Trace-connected Metrics (Analyzers) ([#4840](https://github.com/getsentry/sentry-dotnet/pull/4840))If none of the above apply, you can opt out of this check by adding |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## ref/metrics-stable-api #4840 +/- ##
==========================================================
- Coverage 73.93% 73.93% -0.01%
==========================================================
Files 497 499 +2
Lines 17966 18017 +51
Branches 3516 3527 +11
==========================================================
+ Hits 13284 13321 +37
- Misses 3824 3836 +12
- Partials 858 860 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Provides hierarchical constants for metric units supported by Sentry Relay, organized into Duration, Information, and Fraction categories. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…-metrics-analyzers
…-metrics-analyzers
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Breaking Changes 🛠
Features ✨
Dependencies ⬆️Deps
🤖 This preview updates automatically when you update the PR. |
|
|
||
| Rule ID | Category | Severity | Notes | ||
| --------|----------|----------|------- | ||
| SENTRY1001 | Support | Warning | TraceConnectedMetricsAnalyzer No newline at end of file |
There was a problem hiding this comment.
question: ID
I'm a a bit certain about the ID.
Also, I'm not sure if it should be two separate IDs, one for the Emit* methods, and one for SentryMetric.TryGetValue<TValue>(out TValue value) method.
| https://github.com/SimonCropp/Polyfill | ||
| --> | ||
| <ItemGroup> | ||
| <PackageReference Include="Polyfill" Version="9.8.1" PrivateAssets="all" /> |
src/Sentry.Compiler.Extensions/Analyzers/TraceConnectedMetricsAnalyzer.cs
Show resolved
Hide resolved
src/Sentry.Compiler.Extensions/Analyzers/TraceConnectedMetricsAnalyzer.cs
Show resolved
Hide resolved
src/Sentry.Compiler.Extensions/Analyzers/TraceConnectedMetricsAnalyzer.cs
Show resolved
Hide resolved
|
|
||
| internal static class DiagnosticCategories | ||
| { | ||
| internal const string Sentry = nameof(Sentry); |
There was a problem hiding this comment.
question: Category
I'm a bit uncertain about the Category.
The Category can be used to e.g. configure all Diagnostic of a category, rather than or in addition to configuring specific diagnostics per ID,
e.g. via an .globalconfig file
is_global = true
# Configure this new rule only
dotnet_diagnostic.SENTRY1001.severity = none
# Configure all rules within the "Sentry" Category
dotnet_analyzer_diagnostic.category-Sentry.severity = none
The ideas / variants I am having are
- a single Category for all of Sentry's Diagnostic
- have a Category per Feature set
- e.g.
- Traces
- Logs
- Metrics
- e.g.
- re-use the same Categories that the Analyzers of the .NET SDK include
There was a problem hiding this comment.
I am currently leaning towards a Sentry category (as currently proposed),
as I don't believe we are going to have a significant number of Diagnostics and/or Diagnostics in different Categories anytime soon,
so that users have an easy opt-out to all of our Analyzers if there are any issues.
(to be exemplified / documented via #4962)
| https://github.com/SimonCropp/Polyfill | ||
| --> | ||
| <ItemGroup> | ||
| <PackageReference Include="Polyfill" Version="1.33.2" PrivateAssets="all" /> |
based on (but to be merged to
mainindividually)feat(metrics): Trace-connected Metrics #4834Summary
My little weekend-project:
Add a Diagnostic-Analyzer to our Compiler-Extensions, that warn users when a metric would not be emitted due to an unsupported numeric value type -or- likewise, a
SentryMetric.TryGetValue<>invocation with an unsupported numeric value type is detected.Changelog Entry
Report a new Diagnostic (
SENTRY1001) when a Metrics-API is invoked with an unsupported numeric typeRemarks
For the numeric type of a Metric, we currently allow 64-bit sized integral (signed) and floating-point numbers.
That means that e.g.
ulong,System.Int128, ordecimalare currently not supported by Sentry.The compile-time constraint of
Sentry.SentryMetric<T>only constrains to non-nullable value types.Alternatively, we could have implemented respectively types overloads for the method groups:
To avoid this explosion of overloads per method group,
and be similar to the implementation of System.Diagnostics.Metrics,
we are not compile-time constraining unsupported types,
but are instead run-time constraining unsupported types (no-op and Debug-Diagnostic-Logging).
To still warn users unfamiliar with the System.Diagnostics.Metrics.Meter-based APIs,
I built an Analyzer over some weekends to guide new users.
Examples